Class-3 K8s资源清单

2025-05-05

字数统计: 1.3k字 | 阅读时长≈ 4分

author:魏静崎
2025年5月5日
K8s学习

来源：学习b站薪享宏福Kubernetes课程

1、什么是资源

K8S 中所有的内容都抽象为资源，资源实例化之后，叫做对象。
名称空间级别
工作负载型资源： Pod、ReplicaSet、Deployment …
服务发现及负载均衡型资源: Service、Ingress…
配置与存储型资源：Volume、CSI …
特殊类型的存储卷：ConfigMap、Secre …

集群级资源
Namespace、Node、ClusterRole、ClusterRoleBinding

元数据型资源
HPA、PodTemplate、LimitRange

2、资源清单的编写

五个必须有根对象：apiVersion、kind、metadata、spec、status（不是用户维护，而是Kubernets集群自己维护生成的）
apiVersion： 接口组/版本，格式体现，如：autoscaling/v2，其中有一个单独的v1不是该格式，代表core/v1。
kind： 类别，资源的类别，如Pod、Deployment
metadata： 元数据，对资源对象的描述，如name，所属的namespace（如pod这种名称空间级资源），标签label
spec： 期望，期望所能到达的状态（不一定能成功）
status： 状态，描述期望当前的状态

可以通过kubectl explain +资源名称查询对应的资源信息

常用命令：

# 获取当前的资源，pod  
$ kubectl get pod  
	-A,--all-namespaces 查看当前所有名称空间的资源  
	-n  指定名称空间，默认值 default，kube-system 空间存放是当前组件资源  
	--show-labels  查看当前的标签  
	-l  筛选资源，key、key=value  
	-o wide  详细信息包括 IP、分配的节点  
	-w  监视，打印当前的资源对象的变化部分  
  
# 进入 Pod 内部的容器执行命令  
$ kubectl exec -it podName -c cName -- command  
	-c  可以省略，默认进入唯一的容器内部  
  
# 查看资源的描述  
$ kubectl explain pod.spec  
  
# 查看 pod 内部容器的 日志  
$ kubectl logs podName -c cName  
  
# 查看资源对象的详细描述  
$ kubectl describe pod podName  
  
# 删除资源对象  
$ kubectl delete kindName objName  
	--all 删除当前所有的资源对象

3、Pod的生命周期

initC

init 容器与普通的容器非常像，除了如下两点：
init 容器总是运行到成功（返回码=0）完成为止，失败则重新创建（且从第一个initC开始）
每个 init 容器都必须在下一个 init 容器启动之前成功完成
InitC 与应用容器具备不同的镜像，可以把一些危险的工具放置在 initC 中，进行使用

钩子

Pod hook（钩子）是由 Kubernetes 管理（当前节点）的 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为 Pod 中的所有容器都配置 hook。
Hook 的类型包括两种：exec：执行一段命令、HTTP：发送 HTTP 请求
启动后钩子：是在mainC初始化后执行的，执行启动命令也是，启动后钩子比执行启动命令早开始，但不是串行的，可能在时间上有交叉。
关闭前钩子：关闭前钩子执行完毕后，关闭信号才会执行。

探针

都是通过当前Pod的kubectl完成的。有三种类型的处理程序：
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的

就绪探针

k8s 通过添加就绪探针，解决尤其是在扩容时保证提供给用户的服务都是可用的。
当所有mainC都被标记为就绪，Pod才允许通过负载均衡提供给用户访问（Pod就绪）。
如果pod内不添加就绪探测，则默认就绪。

存活探针

k8s 通过添加存活探针，解决虽然活着但是已经死了的问题。比如一个服务还在，但是依赖于它的服务（实际给用户访问的）已经不在了（假死）。

启动探针

k8s 在 1.16 版本后增加 startupProbe 探针，主要解决在复杂的程序中 readinessProbe、livenessProbe 探针无法更好的判断程序是否启动、是否存活。（比如存活探测过早还没初始化完成，或者过完又发生问题）

弹幕说：在存在启动探针的情况下，存活探针的initialdelayseconds配置无效，并且会在启动探针通过后，立即开始存活探针探测。

延伸

在 k8s 中，理想的状态是 pod 优雅释放，但是并不是每一个 Pod 都会这么顺利
Pod 卡死，处理不了优雅退出的命令或者操作
优雅退出的逻辑有 BUG，陷入死循环
代码问题，导致执行的命令没有效果

对于以上问题，k8s 的 Pod 终止流程中还有一个 “最多可以容忍的时间”，即 grace period ( 在 pod.spec.terminationGracePeriodSeconds 字段定义)，这个值默认是 30 秒，如果我们配置的 grace period 超过时间之后，k8s 就只能选择强制 kill Pod，这将不会等待关闭前勾子完成。

4、Pod是如何被调度运行的

本文作者： 魏静崎
本文链接： https://slightwjq.github.io/2025/05/05/K8s学习-3 K8s资源清单/
版权声明： 该文章来源及最终解释权归作者所有